Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / cat / cat-minutes-92mar.txt < prev next >

Wrap

Text File | 1993-02-17 | 13.9 KB | 420 lines

These Minutes are a rough draft only - Megan 04/03/92 Common Authentication Technology (CAT) meeting minutes, San Diego IETF, 16-17 March 1992 [Note: Jeff Schiller took an additional set of meeting notes which include pictures and which are available (in PostScript form) by anonymous FTP from bitsy.mit.edu with pathname: /cat-ietf/cat-wg-mar92-jis-picurenotes.ps ] The March CAT meetings included discussion of standards advancement plans, and of interface extension requests made by ICL in support of ECMA authorization architecture. Most of the discussion was spent, however, on the evolving topic of a unified Internet authentication mechanism hybridizing Kerberos secret-key and DASS public-key technologies. STANDARDS AND ROLLOUT PLAN John Linn led a standards plan discussion, the result of which was a decision to recommend the GSS-API interface specifications for advancement to proposed standards. We anticipate that Kerberos and DASS specifications, as well as a specification for the planned unified mechanism, will follow in succession onto the standards track. Two previously-cited technical topics regarding GSS-API were raised in this discussion: (1) the prospect of additional interfaces oriented to stream-oriented integration (as with UNIX(tm) sockets), tabled as being separately definable later in an upwardly-compatible fashion, and (2) the prospect of adding callouts so that user input (e.g., for passwords or hand-held authenticator information) could be collected at context establishment time. (2) was tabled because of lacking implementation experience, possible OS-specificity of approaches, and consideration that such data might more securely be acquired through end system trusted path facilities than via application mediation. ICL COMMENTS AND ECMA SECURITY ARCHITECTURE P. Rajaram stood in for Piers McMahon of ICL (who was unable to attend the meeting) in leading a discussion based on Piers' message as forwarded to the mailing list. Piers' message proposed interface extensions (GSS_Modify_Cred and GSS_Get_Attributes primitives) to support authorization features of the ECMA security architecture (as described in ECMA reports TR/46, TR/138), and Raj presented an overview of that architecture, the slides from which are included as an appendix to these minutes. Interest was expressed in the prospect of having the ECMA reports available in FTP-accessible on-line form. In group discussion, it was recognized (consistent with discussion at the SAAG) that specific authorization support features, and related extensions in support thereof, would comprise a likely area for future IETF security work. Such work would consider not only ECMA inputs but also contributions from the Kerberos community as well as other sources, selecting an approach or defining a core intersection of multiple approaches. Any and all relevant inputs would be solicited. As with other Internet standards, prototyping results would be necessary for advancement. Lacking a concrete Internet community decision to adopt the ECMA architecture, no decision to incorporate the ECMA extension requests at this time was taken. Raj suggested that it might be useful to convene a BOF at a subsequent IETF meeting to further familiarize interested IETF participants with the ECMA architecture. Specific points raised in ECMA-related discussion: To acquire a Privilege Attribute Certificate (PAC), a subject contacts a server. The PAC contains a sequence of attribute triples {type, authority, value} which govern the ways in which the PAC can be used, and an audit ID which alows audit accountability for actions independent of the privileges on which access controls are based, among other elements. Confusion was expressed about the circumstances under which a PAC must be confidentiality-protected in transfer, and about whether concurrent and separate authentication was necessary in order to demonstrate oneself as an authorized user of a particular PAC. Some of the answers were thought to depend on the particular attributes bound into the PAC, per definitions in ECMA TR/138. UNIFIED AUTHENTICATION MECHANISM John Linn gave an overview of goals for the effort, Charlie Kaufman and Cliff Neuman presented alternative technical options, and Jeff Schiller led a discussion to collect requirement and priorities inputs to be considered in selecting among available alternatives. OVERVIEW OF EFFORT John's overview slides contained the following points: DASS-Kerberos Unification: How Did We Get Here? - Cross-mechanism portability addressed in CAT - Suggestion at Santa Fe SAAG: support universal interoperability for strong Internet authentication - Kerberos and DASS designers and architects met in a series of interim meetings Where are we going? - Internet-Draft documentation of hybrid mechanism to fit under CAT/GSS-API framework - Ability to migrate applications from already-defined mechanisms to hybrid when available - Common token format which can accommodate both public-key and secret-key authentication processes Premises - Domains and endpoints can be built native to Kerberos-like secret-key and DASS-like public-key technologies; all endpoints can interoperate - Support for user, host, and process principals, represented by cryptographic keys - Global naming (plan: X.500 Distinguished Names as basis within mechanism), trust path tied to naming hierarchy Goals - PEM X.509 certificate infrastructure usable as a basis for scaling - Domains equipped with public-key technology can operate without establishing on-line authentication servers - Domains can be constructed without public-key technology - Self-sufficient startup: can form a domain in isolation and later incorporate it into the broader hierarchy - Can transport user-provided data (undefined by us) restricting the use of authentication tokens - Avoid need for endpoints to contact foreign-mode support servers (KDCs, certificate stores, ...) Strong Authentication - Successful authentication requires either: -- current possession of principal's key -- principal's authorization to act for principal with other (short-term) key + demonstration of that key - Intercepted tokens can't be used by attackers to build new tokens for masquerade, or be successfully replayed outside narrow window Four Directions - (We believe all can be made to work, and seek to resolve priorities and tradeoffs) -- SK endpoints add complexity to interwork with PK -- PK endpoints add complexity to interwork with SK -- "Client makes right" -- "Server makes right" Issues and Tradeoffs - Interoperability with existing/emerging technology bases - What entities can accommodate complexity and performance demands? - What entities can and can't be changed feasibly? - What entities must perform what crypto-functions? ALTERNATIVE TECHNICAL APPROACHES Charlie noted that support for interoperability between Kerberos-native and DASS-native authentication peers wasn't (unlike cross-mechanism portability) a chartered goal of GSS-API, and that it was a positively surprising result to discover upon investigation that such support within a unified mechanism below the interface in fact appeared to be possible, via any of several approaches. We confirmed the fact that the ability to support global scaling was intended. Charlie's presented approach has the following characteristics: - SK endpoints need not perform RSA operations or communicate with certificate stores - PK endpoints need not communicate with KDCs and the security of authentication between PK endpoints cannot be compromised by faulty KDCs It imposes the following impacts on particular system components: - no impact on SK client - PK clients and servers must be able to end treewalks at a GKDC and use that GKDC's key in token generation and processing - SK server must interact with KDC to process incoming tickets arriving from PK domains - GKDC must be able to create and open PK tickets The fact of crossing from a public-key to a secret-key domain (or vice versa) needs to be determinable in a trusted fashion; naming prefix rules play an important part in this determination. Cliff Neuman began the second CAT session by presenting an approach which matched Charlie's for the case of an SK client accessing a PK server, using tickets signed with the private key of a GKDC and integrable into the unified ticket format. It was observed that adoption of the unified format (in contrast, e.g., to use of Kerberos V5 tokens for SK cases) would require some level of change to all presently-extant peer systems. Cliff presented an alternative approach for the case of a PK client accessing a SK server. A goal of this alternative was to avoid the need for a SK server to contact the GKDC, since such communication requires that the SK server be stateful in a manner divergent from the current Kerberos operational model. Cliff's proposal included a "Gateway Certificate Distribution Center" or GCDC, to which PK clients would DASS-authenticate and would receive, in response, a Kerberos ticket for the target SK server along with an associated encrypted session key. The GCDC, not the target server, would mediate interactions with intermediary SK authentication servers. In order to support both SK->PK and PK->SK accesses under this model, both GKDCs and GCDCs would be required; while these functions are logically distinct, they could likely be colocated. Cliff summarized the impact which his proposal would impose on particular system components as follows: - no impact on SK client - PK client must use different protocol in interacting with the last CDC in an outbound chain - no impact on SK server - PK server impact equivalent to Charlie's proposal - GKDC and GCDC must be able to create and open PK and SK tickets on behalf of clients REQUIREMENTS/PRIORITIES EVALUATION Jeff Schiller led a discussion at the end of the meeting with a goal of soliciting group inputs on requirements and priorities for the unified mechanism. We created a comparison matrix, and the exercise's results served to validate many of the assumptions adopted by the designers. In particular, the group showed popular acceptance for the idea of a dual-mode approach which employs PK and SK techniques for different cases. It was noted that allocation of computationally-intensive functions among components would be an additional useful metric, though not one which was included within this analysis. Criteria included: - free availability of software, in terms of licensing, anonymous FTP-ability (ranked #3 criterion) - availability of source code implementations (ranked #2 criterion) - ability of approach to scale to world (by a broad margin, ranked as #1 criterion) - avoidance of on-line trusted KDCs (ranked #4 criterion) - simplicity/elegance of approach (construed by some attendees as equivalent to verifiability of protocol) - client simplicity (ranked #5 criterion, more important than server simplicity) - server simplicity - compatibility with existing Kerberos (relatively low priority) - compatibility with SPX (lower priority than Kerberos compatibility) APPENDIX: P. RAJARAM SLIDES ON ECMA SECURITY ARCHITECTURE -----1----- rajaram@sun speaking-for piers-mcmahon@icl Motivation: - Extend GSS-API to enhance . Authorization (useful to Kerberos-5) . Delegation (more than just ON/OFF) - Strategy . Don't modify existing API . Add a few new interfaces -----2----- SUMMARY of ECMA SECURITY ARCHITECTURE - European Computer Manufacturers Assoc. - This framework developed by a working group TC-32 / TG-9 - Supports many security models . ACL based . Capability based . Label based (MAC) & . Extensible combinations of above - 10 security facilities . promote modularity . support interdomain security . allow interoperability -----3----- The 10 SECURITY FACILITIES . Authentication Service . Privilege Service . Subject Sponsor . Cryptographic Service . Secure Association . Authorization Service . Interdomain Service . Audit . Security Recovery . Security State -----4----- Subjects and Objects Subjects access Objects Subjects and Objects have Security Attributes Subject Privilege Attributes . Identity, Group . Role . Clearance Object Control Attributes . ACLs . Information Labels . Classifications Ultimately, access is granted only if the Subject's privilege attributes "dominate" the Object's control attributes. -----5----- Privilege Attribute Certificate Contains: . a Sequence of Attributes { Type, Authority, Value } . Validity times . Contained PACs . Audit identity . Signing Authority name (Domain authority) . Signature The last two are required. -----6----- Simple Model +-----+ | APS | Authentication and +-----+ Privilege Service ^ | Auth | | PAC | v +---------+ +--------+ | Subject |------------------------>| Object | +---------+ \ PAC +--------+ \ \ +--------+ \------------------->| Object | PAC +--------+ 1) Subject authenticates itself to APS 2) Subject receives PAC 3) Subject offers PAC to Object and receives requested service. A PAC contains both Identification AND Authorization info. -----7----- . A PAC need not contain a Subject Identifier. . An anonymous PAC may contain only a security clearance, and an audit ID. . This may be enough to authorize access. . Kerberos 5 and Kerberos/DCE can benefit from proposed API -----8----- Proposed API (greatly simplified) GSS-Modify-Credentials . [In] Cred handle . [In] { Attributes & Values} ... . [In/Out] Credentials GSS-Get-Attributes . [In] Cred handle . [In] Requested Attributes . [Out] Returned {Attributes & Values} -----9----- Discussion: . GSS-API: for authentication only ? . Allow for ECMA, in addition to Kerberos & DASS ? . CAT --> CAAT . ECMA BOF ?